Access to Content

In Resolve Actions Pro, you control access to content using namespaces. Each ActionTask, Wiki, Automation, and so on is always created in a namespace. After you have a namespace hierarchy in place, you can control which roles have access to which namespace. With some content, you can override the namespace’s default permissions for the content item alone.

• Administrators can set up namespaces with suitable Role-Based Access Control (RBAC) to incorporate developers from different teams and with different permissions into the ecosystem.
• Developers are responsible for setting up a default RBAC for the namespaces they oversee. This way they can rest assured that changes by other developers will not adversely affect other people’s work.

For example, you could create a namespace for a team or a single developer and only allow them to create content in it. You can choose to give others read access or lock them out completely from the namespace.

How Namespaces Work

There are several rules to have in mind when working with namespaces in Actions Pro:

• Choosing a namespace is mandatory when creating content, including Automations, Decision Trees, Wiki Pages, ActionTasks, and ActionTask Properties. You cannot create content outside of the namespace hierarchy.
• Namespaces are hierarchical:
  • Unless you make manual adjustments, permissions from the parent namespace propagate down to all children or individual content items.
  • You can create, copy, or move content from one sub-namespace to another, according to your access permissions, but you cannot copy or move an entire namespace.
• Namespace names cannot be empty and can contain only alphanumerical characters, underscore, space, and dash.
• Importing content under the resolve namespace or a sub-namespace is allowed only to the resolve.maint user.
• Administrators can modify the RBAC settings of all content and namespaces, including adding or removing roles.

Managing Namespaces

You can manage namespaces from a central location: Main Menu > Wiki Administration > Namespace Administration. Which namespaces you see or can manage under Namespace Administration depends on your role.

Creating a Namespace

Any role can create namespaces provided it has the right permissions:

• As an administrator, you will most likely create top-level namespaces for different teams or individuals.
• As a developer, you will create either top-level namespaces or sub-namespaces in namespaces created by an administrator.

There are two ways to create a namespace: from Namespace Administration or on the fly.

note

After you create a namespace, you cannot move it under another namespace.

Creating a Namespace from Namespace Administration

As an administrator, who doesn’t create content on a regular basis, you will most likely create namespaces on request using Namespace Administration.

note

Namespaces created from Namespace Administration receive the following RBAC settings on creation:

• Root-level namespaces receive the default RBAC settings.
• Sub-namespaces receive the RBAC settings of their direct parent.

In both cases, you can change the namespace’s RBAC by going to Wiki Administration > Namespace Administration.

Follow these steps to create a new namespace using Namespace Administration:

1. From the Actions Pro main menu, click Wiki Administration > Namespace Administration.
2. In the tree on the left, select where to create the namespace:
   • To create a top-level namespace, ensure that All is selected.
   • To create a sub-namespace, select a namespace to serve as a parent namespace to the one you are creating.
     You can nest namespaces on multiple levels.
3. Click Create Namespace.
   The Create Namespace dialog box appears.
4. Fill in the form and finally click Create Namespace.
   • Parent Namespace—This field allows you to change the parent namespace if you haven’t selected the right one beforehand.
   • Root Level Namespace—This field allows you to create the namespace as top-level even if you have selected a parent namespace.
     Checking this option disables the Parent Namespace field.
   • Namespace Name—Give the namespace a name.
     Namespace names cannot be empty and can contain only alphanumerical characters, underscore, space, and dash.
     You cannot change the namespace’s name after you create it.

New namespaces can be used by other users immediately.

You can set the namespace’s RBAC immediately after creating the namespace.

Creating a Namespace On the Fly

As a developer who creates content on a regular basis, you have the option to create namespaces as you are creating the content instead of doing so beforehand.

note

Namespaces created on the fly use the default RBAC settings, regardless of the parent namespace’s permission. To change the namespace’s RBAC, go to Wiki Administration > Namespace Administration.

On-the-fly namespace creation is dependent on your role’s permissions over the parent namespace (or whether the role is allowed to create root-level namespaces under All—see Setting Default Namespace Permissions. You need the WRITE permission to be able to create sub-namespaces.

You always need to provide a target namespace when creating content. The steps to do so depend on the content type. In all cases though, in addition to selecting an existing namespace, you have the option to enter a namespace name. The namespace and its parents will be created if it doesn’t already exist:

• To create a top-level namespace, enter a single namespace name.
  Example: teamlinux
• To create a sub-namespace, use the dot notation to prefix it with its full parent hierarchy:
  Example: teamlinux.fedora.security

note

To prevent typing errors, you can use a combination of selection and typing. Assume you want to create the security namespace in the existing teamlinux.fedora namespace. Instead of typing teamlinux.fedora.security, select it from the list and then add ".security" at the end.

Modifying a Namespace

After you create a namespace, you can’t change its name or parent anymore. In terms of allowed modifications, you can only modify its RBAC.

note

The changes to the namespace RBAC applies to all new and existing content in the namespace that has no overrides applied.

Take these steps to modify a namespace:

1. From the Actions Pro main menu, click Wiki Administration > Namespace Administration.
2. In the tree on the left, select the namespace to modify.
3. Click the Edit Roles button.
4. Specify what roles have permissions over the namespace:
   • To give a new role permissions over the namespace, click Add Roles and select the role to add.
     Multiple selection is possible in the Role List dialog box.
   • To revoke all permissions from a role, click the Minus icon in front of its name in the list.
5. Specify what permissions each role has:
   • Check the Read, Write, Execute, and Admin boxes for a role to give it the respective permissions. Uncheck the boxes to revoke the permission.
     See Role Permission Types to understand how each permission works.
   • If you revoke all four permissions from a role, the role will be removed from the list on save.
   • Selecting Admin implies Read, Write, and Execute, that’s why you cannot set them separately.
   • Selecting Write or Execute implies Read, that’s why you cannot set it separately.
6. Click Save Changes.

RBAC changes take effect immediately after saving.

Deleting a Namespace

You can only delete an empty namespace. If any content exists in the namespace, you get an error message when trying to delete it. See Identifying All Content in a Namespace to lean how to find what content you need to delete before deleting a namespace.

Take these steps to delete a namespace:

1. From the Actions Pro main menu, click Wiki Administration > Namespace Administration.
2. In the tree on the left, select the namespace to delete.
3. Click the Delete Namespace button.
4. Confirm the deletion.

Role Permission Types

When defining a namespace’s or a content’s RBAC, you can give a set or permissions to one or more roles to determine what the role can do with it. The table below describes what each permissions means.

When customizing a namespace’s permissions to selectively share or hide content, the change takes effect immediately but the content may take a couple of minutes to show up in the Content Browser.

Title	Description
READ/View	A role with READ permission can only perform the following operations with the namespace or the content: - View it - For namespaces, view the list of content in the namespace, excluding content with custom permissions that doesn't include the READ permission for the role - For namespaces, view content in the namespace, excluding content with custom permissions that doesn't include the READ permission for the role
WRITE/Edit	The WRITE permission implies READ. A role with WRITE permission can perform the following operations with the namespace or the content. For namespaces: - Create new content in the namespace - Edit and save content in the namespace - Copy content inside the namespace For content: - Edit and save the content (excluding setting RBAC)
EXECUTE	The EXECUTE permission implies READ. A role with EXECUTE permission can perform the following operations with content in the namespace: - Execute Automations - Execute Decision Trees - View the results of an execution
ADMIN	The EXECUTE permission implies READ, WRITE, and EXECUTE. A role with ADMIN permission can perform the following operations with the namespace or the content: - Modify the RBAC, including adding or removing roles - Override RBAC inherited from the parent namespace on namespace or content level - Delete content inside the namespace - Undelete content inside the namespace - Purge content inside the namespace

System Namespaces

Actions Pro comes with a few built-in namespaces. It is not recommended to manually create content in these namespaces as they might be removed or changes in a future Actions Pro version.

The system namespaces are:

• resolve_admin—used exclusively by the GIT_PATH ActionTask property. It provides ADMIN access to the admin, resolve_dev, resolve_process, and resolve_user roles. It is not recommended to modify the namespace’s default RBAC.
• ResolveContent—meant to serve only admin role users where they have full access. Other users are limited to READ access.
  • Content in ResolveContent cannot be created, updated or deleted from the UI or HTTP APIs. If you need to edit an ActionTask from this namespace, copy it to another namespace first.
    An error message is presented stating that this is a restricted namespace.
  • Any new role that you create automatically receives READ access to the namespace.
  • The admin role can create and update content in ResolveContent using package import.
    Non-admin users trying to import content in the namespace receive an error in the import log.
• common—Common utilities.
• CR—Deprecated. Content relating to Content Request.
• Reports—Standard reports.
• resolve—Contains ActionTasks and other content pre-built by Resolve. Do not edit or create new content in this namespace. If you need to edit an ActionTask from this namespace, copy it to another namespace first.
• ResolveExplorer—Deprecated Wiki pages.
• ResolveIntro—Content used by the tutorial available on the Dashboard (Actions > Dashboard > Resolve Intro).
• Runbook—Deprecated content.
• system—System Runbooks. Do not edit or create new content in this namespace. If you need to edit an ActionTask from this namespace, copy it to another namespace first.
• SystemAdmin—Deprecated content.
• template—Deprecated content.

Setting Default Namespace Permissions

Using system properties, you can make a number of default settings relating to namespaces such as default roles and default permissions. Most of them have default values out of the box.

Take these steps to set the namespace system properties:

1. From the Actions Pro main menu, click System Administration > System Properties.
2. In the filter text box at the top enter the system property name end press Enter to find it.
3. Click the Edit icon in front of the property’s name.
4. In Value, enter the new value and click Save.

See the list below for namespace system property usage:

• namespace.rights.creation.roles—Comma-separated list of role names that are allowed to create root-level namespaces. An empty value means all roles are allowed.
• namespace.rights.admin.default—Comma-separated list of role names that will receive the ADMIN permissions by default over new root-level namespaces and namespaces created on the fly. You will be able to remove this permissions after you create the namespace. An empty value means all roles receive the permissions.
• namespace.rights.edit.default—Comma-separated list of role names that will receive the WRITE/EDIT permissions by default over new root-level namespaces and namespaces created on the fly. You will be able to remove this permissions after you create the namespace. An empty value means all roles receive the permissions.
• namespace.rights.execute.default—Comma-separated list of role names that will receive the EXECUTE permissions by default over new root-level namespaces and namespaces created on the fly. You will be able to remove this permissions after you create the namespace. An empty value means all roles receive the permissions.
• namespace.rights.view.default—Comma-separated list of role names that will receive the READ/VIEW permissions by default over new root-level namespaces and namespaces created on the fly. You will be able to remove this permissions after you create the namespace. An empty value means all roles receive the permissions.
• search.exclude.namespace—Comma-separated list of namespace names to be excluded from the Content Manager tree and searches inside it.
• dashboard.namespace.exclude—For system use.
• help.context.namespace—For system use.

Identifying All Content in a Namespace

You might need to list all content that users have created in a namespace, especially before deleting a namespace. You can do that using the Content Manager.

Take these steps to list all content in a namespace:

1. From the Actions Pro main menu, click Content Management > Content Manager.
2. On top of the tree on the left, set the Browse by filter to Namespace.
3. In the tree, select the namespace that you want to list.

The namespace’s content appears on the right divided into categories. Stay on the All tab to view the full list or switch to Wikis, Automations, or Custom Forms to see only the respective content types.

Setting Content Permissions

Although the permissions that you can assign to content are always the same four types, the procedure to do so depends on the content type.

By default, the content that you create inherits its parent’s permissions but you can customize them.

Setting ActionTask Permissions

New ActionTasks inherit their permissions from their parent namespace. Most of the time, this is what you want, but you can also override the inheritance.

Take these steps to customize the permissions of an ActionTask:

1. From the Actions Pro main menu, click Content Management > Content Manager.
2. Find the ActionTask that you want to modify and open it.
3. Click the Edit icon at the top-right to enter edit mode.
4. Go to the General tab and then to the Roles tab.
5. Uncheck the Apply Default Roles check box.
6. Set custom permissions:
   • To modify the permissions of the currently listed roles, in the table, use the check boxes to modify the permissions.
   • To completely revoke a role’s permissions, in the table, click the Minus icon in the last column.
   • To add a new role, use the Add Role section below the table:
     1. In Name, select a role.
     2. In Access, use the check boxes to give the role the permissions you want.
     3. Click Add Role.
7. Click the Save icon at the top-right to save the ActionTask.

Setting ActionTask Property Permissions

ActionTasks Properties always inherit their permissions from their parent namespace. Unlike some other content types, you cannot override the inheritance.

Setting Automation, Wiki Page, and Decision Tree Permissions

The permissions of all three components of an Automation: the Wiki page, the Automation model, and the Decision Tree are set together, regardless of whether you are using all three components.

New Automation inherit their permissions from their parent namespace. Most of the time, this is what you want, but you can also override the inheritance.

Take these steps to customize the permissions of an Automation:

1. From the Actions Pro main menu, click Content Management > Content Manager.
2. Browse the namespace tree and find the Automation, Wiki page, or Decision Tree that you want to modify and open it.
3. Click the Edit icon at the top-right to enter edit mode.
4. Go to the Page tab.
5. Open the File menu at the top-left and select Properties.
6. Under Roles, uncheck the Apply Default Rights check box.
7. Set custom permissions:
   • To modify the permissions of the currently listed roles, in the table, use the check boxes to modify the permissions.
   • To completely revoke a role’s permissions, select the role and then click Remove.
   • To give permissions to a different role, click Add and select it and then specify its permissions.
8. Click Update.
9. Save the Automation, Wiki page, or Decision Tree.

Setting Custom Forms Permissions

Custom Forms exist outside of the namespace model and use a simplified admin/view access model.

Take these steps to customize the permissions of a Custom Form:

1. From the Actions Pro main menu, click Table Administration > View Forms.
2. Click the View Details icon in front of the custom form that you want to manage.
3. In the right panel, ensure that the Form Settings tab is selected.
4. Under Access Rights, set permissions:
   • To modify the permissions of the currently listed roles, in the table, use the check boxes to modify the permissions.
   • To completely revoke a role’s permissions, select the role and then click Remove.
   • To give permissions to a different role, click Add and select it and then specify its permissions.
5. Click Save.